PR Stack (Queue Instrumentation)

• feat(core): [Queue Instrumentation 1] Add enableQueueTracing option and messaging span data conventions #5250
• feat(samples): [Queue Instrumentation 2] Add Kafka to Spring Boot 3 sample app #5253
• feat(spring-jakarta): [Queue Instrumentation 3] Add Kafka producer instrumentation #5254
• feat(spring-jakarta): [Queue Instrumentation 4] Add Kafka consumer instrumentation #5255
• feat(spring-boot-jakarta): [Queue Instrumentation 5] Add Kafka queue auto-configuration #5259
• test(samples): [Queue Instrumentation 6] Add Kafka queue system tests #5260
• feat(samples): [Queue Instrumentation 7] Add Kafka to Spring Boot 3 OTel sample apps #5265
• fix(spring-boot-jakarta): [Queue Instrumentation 8] Disable Sentry Kafka spans when OTel is active #5274
• fix(spring-jakarta): [Queue Instrumentation 9] Clean up stale ThreadLocal context in Kafka consumer interceptor #5279
• fix(spring-jakarta): [Queue Instrumentation 10] Fork root scopes and skip when OTel is active in Kafka consumer #5280
• fix(spring-jakarta): [Queue Instrumentation 11] Guard entire span lifecycle in Kafka producer interceptor #5281
• fix(spring-jakarta): [Queue Instrumentation 12] Add Kafka retry count attribute #5282
• fix(spring-jakarta): [Queue Instrumentation 13] Align enqueue time with Python #5283
• ref(kafka): [Queue Instrumentation 14] Extract sentry-kafka module #5288
• feat(samples): [Queue Instrumentation 15] Add opt-in Kafka console e2e coverage #5289
• fix(test): [Queue Instrumentation 16] Enable Kafka profile in system runner #5291
• feat(kafka): [Queue Instrumentation 17] Add manual consumer tracing helper #5312
• ref(samples): [Queue Instrumentation 18] Move Kafka sources into queues.kafka package #5313
• ref(samples): [Queue Instrumentation 19] Drop Kafka auto-config exclude from Spring Boot samples #5314
• ref(kafka): [Queue Instrumentation 20] Log Kafka instrumentation failures #5315
• fix(kafka): [Queue Instrumentation 21] Preserve third-party baggage on Kafka producer records #5316

📜 Description

Log Throwables caught inside Kafka instrumentation instead of silently swallowing them.

Affected catch sites:

• SentryKafkaProducerInterceptor.onSend(...) — wrapping span creation and header injection.
• SentryKafkaConsumerTracing.withTracingImpl(...) — forking scopes + makeCurrent().
• SentryKafkaConsumerTracing.startTransaction(...) — transaction creation.
• SentryKafkaConsumerTracing.finishTransaction(...) — transaction finish.

All catches still swallow the throwable so instrumentation failures never break the customer's Kafka send or record processing. The only change is that the failure is now reported to the SDK's own logger at SentryLevel.ERROR (same pattern already used in RequestPayloadExtractor).

SentryKafkaRecordInterceptor (Spring Jakarta) was audited alongside — it does not wrap instrumentation in catch (Throwable) blocks, so there is nothing silent to log. The existing NumberFormatException branches on malformed sentry-task-enqueued-time headers are expected input, not instrumentation faults, and remain silent both in the Spring interceptor and in SentryKafkaConsumerTracing.receiveLatency(...).

💡 Motivation and Context

The raw Kafka instrumentation in sentry-kafka deliberately fails open: if anything throws while Sentry tries to start/finish a span or inject tracing headers, the customer's Kafka operation still succeeds. That behavior is correct and is preserved here.

What was missing was any trace of such a failure. With catch (Throwable ignored), an instrumentation bug would be invisible in production — neither the customer nor us would know the SDK was quietly failing. Surfacing it through the SDK logger matches how other integrations report unexpected internal failures (e.g. RequestPayloadExtractor in Spring Jakarta) and makes these paths debuggable without changing fail-open semantics.

💚 How did you test it?

• ./gradlew :sentry-kafka:compileJava — clean.
• ./gradlew :sentry-kafka:test — all tests pass, including the existing SentryKafkaConsumerTracingTest and SentryKafkaProducerInterceptorTest suites.
• ./gradlew spotlessApply apiDump — clean.

Behavior verified by reading: catches still swallow the throwable and fall back exactly as before; only additional effect is a single logger.log(ERROR, msg, t) call per caught throwable.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.

🔮 Next steps

If the NumberFormatException header-parse branches ever prove useful to debug, they could be downgraded to DEBUG logs. Leaving silent for now since a malformed sentry-task-enqueued-time header is a data-shape issue, not an SDK fault.

#skip-changelog

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.